Performance Test Comparison Data Of Native Ip Taiwan And Virtual Ip In Terms Of Delay And Packet Loss

question 1: what are the common differences in latency between native ip (taiwan) and virtual ip?

in many of our tests, native ip (taiwanese nodes) usually exhibits more stable and lower latency (rtt), with a typical average value in the 20–50ms range; while most types of virtual ip (via tunnels/proxy/anycast, etc.) often have delays of 40–150ms under the same conditions, and have greater jitter. the main reasons for the difference include routing hop count, packet forwarding layer (nat/proxy), tunnel encapsulation overhead, and operator interconnection link quality.

test environment description

the test was conducted on the same test machine to compare the taiwanese native ip directly connected to the local isp and several common virtual ip services (such as overseas vpn, global anycast cdn export and cloud vendor elastic ip). test tools include ping (icmp rtt), traceroute (path analysis) and iperf /tcpdump (throughput and packet capture).

typical latency data example

sample data (average rtt/ms): taiwan native ip: 28ms; virtual ip (same isp penetration type): 65ms; virtual ip (cross-border tunnel type): 110ms. jitter (standard deviation) is about 3–8ms for native ip and up to 15–40ms for virtual ip.

key factors affecting latency

key factors include: physical link distance, bgp routing policy, layer 2 tunnel (such as gre/ipsec) encapsulation delay, carrier interconnection point congestion, and transit node cpu/queuing delay. under normal circumstances, native ip has natural advantages in direct routing and links.

question 2: what is the difference in packet loss rate between the two?

overall, the packet loss rate is usually very low ( 0–0.5% ) on a stable native link, and can rise to 1%+ during occasional peaks or link jitters. in a virtual ip environment with additional tunnels or multi-level forwarding, the packet loss rate is more likely to be triggered, usually in the 0.5–5% range, and even higher in extreme cases, especially when there is congestion or poor isp interconnection quality.

typical scenarios of packet loss

virtual ip will introduce additional queuing and retransmission when passing through the intermediate proxy or load balancer; if the intermediate node cpu or buffer is limited, the probability of packet loss increases under high concurrency. mtu mismatch in cross-border tunnels can also lead to fragmentation and packet loss.

example of measured packet loss data

sample (30 minutes of icmp sampling): taiwan’s native ip average packet loss rate is 0.12%; virtual ip (domestic penetration) 0.8%; virtual ip (overseas tunnel) 1.9%; during the operator’s link congestion window, virtual ip peak packet loss can reach 6% or higher.

recommended points for detecting packet loss

it is recommended to use continuous long-term sampling (such as ping/iperf for 5–30 minutes), combined with bidirectional detection (client to server and reverse path), and use traceroute to confirm whether packet loss is concentrated on a certain hop or spread across multiple hops.

question 3: how to design testing methods and tools to obtain reproducible data?

to obtain reproducible delay and packet loss comparison data , test design should pay attention to: fixed time window, repeated sampling, multiple regions and multiple time periods, removing occasional values/taking median and p95 and other statistical indicators. commonly used tools include: ping (delay and packet loss), mtr (continuous traceroute+statistics), iperf3 (throughput/packet loss/delay jitter), tcpdump (packet capture evidence), and bgp route viewing tools.

data sampling and statistical indicators

it is recommended to use 1 ping per second for at least 15 minutes to calculate the average, median, p90/p95, standard deviation and packet loss rate. when comparing, a 95% confidence interval or box plot should be given to show the jitter distribution.

how to avoid distractions

during the test, close local high-traffic applications, fix the test time period (avoiding network peaks or specifically doing peak comparisons), and repeat the test at different isps and different physical locations to ensure that the results are representative.

key points for recording and reproducing

save all original data (ping log, mtr output, iperf output, traceroute path) and test configuration (mtu, encryption method, tunnel type, node ip) to facilitate problem location and reproduction.

question 4: how should the performance of the two types of ip be interpreted in different business scenarios (games, real-time audio and video, api requests)?

a small delay difference has limited impact on static page loading or background api, but in real-time interactive services (online games, voip/video conferencing), low latency and low packet loss are crucial. general recommendations: for real-time services, give priority to using native ip (taiwan) or direct egress to ensure lower rtt and more stable packet loss rate; for services with high tolerance that can use cdn or retry mechanism, consider using virtual ip in exchange for flexibility and distribution capabilities.

threshold recommendations for games and real-time audio and video

the ideal rtt for real-time games is <50ms, and packet loss is <1%; the lower the audio and video delay, the better, the jitter should be controlled within 30ms, and the packet loss is preferably <1%, and cooperate with fec/retransmission.

fault tolerance strategy for api business

a higher rtt (<200ms) is acceptable for ordinary api requests, but stability and availability must be ensured. it is recommended to implement reasonable retry, idempotence and request timeout strategies on the client, and use health checks and multi-node switching at the same time.

key points of business selection suggestions

select according to business priority: real-time sensitive -> native ip/direct connection; distribution/caching type -> virtual ip/cdn. and use observable data (p95 delay, packet loss rate, connection success rate) as the basis for decision-making.

question 5: based on the test data, how to optimize to reduce latency and packet loss?

the optimization path is divided into two categories: network layer and application layer. items that can be optimized at the network layer include: optimizing direct routes and bgp neighbors, avoiding unnecessary tunnel encapsulation, optimizing mtu and tcp mss, and negotiating with operators to improve the quality of interconnection points. the application layer can adopt retries, parallel requests, moving traffic to nearby nodes, adding redundant paths and fec, etc.

specific implementation steps

1) use traceroute to locate high-latency/packet loss hops; 2) communicate with upstream/transit operators to reroute or optimize interconnection points; 3) replace with native ip or nearest exit when possible; 4) enable retry, exponential backoff, and connection pooling on the application side.

monitoring and backtesting

deploy continuous observation (sla alarm), automated backtesting (comparison before and after a/b switching), and make horizontal comparisons after each network adjustment to ensure that the adjustment actually improves p95 latency and packet loss.

things to note

optimization requires a balance between cost and complexity: in some cases, switching to dedicated lines or single-point direct connections to achieve small latency improvements is costly, and data-driven evaluation of the investment-output ratio should be applied.